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Case-Sensitive String Support in ABNF 


Abstract 
This document extends the base definition of ABNF (Augmented Backus- 
Naur Form) to include a way to specify US-ASCII string literals that 
are matched in a case-sensitive manner. 
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1. Introduction 


The base definition of ABNF (Augmented Backus-Naur Form) supports US- 
ASCII string literals. The matching of these literals is done in a 
case-insensitive manner. While this is often the desired behavior, 
in some situations, case-sensitive matching of string literals is 
needed. Literals for case-sensitive matching must be specified using 
the numeric representation of those characters, which is inconvenient 
and error prone both to write and read. 


This document extends ABNF to have two different types of US-ASCII 
string literals. One type is matched using case-sensitive matching, 
while the other is matched using case-insensitive matching. These 
types are denoted using type prefixes similar to the type prefixes 


used with numeric values. If no prefix is used, then case- 
insensitive matching is used (as is consistent with previous 
behavior). 


This document is structured as a set of changes to the full ABNF 
specification [RFC5234]. 


2. Updates to RFC 5234 


This document makes changes to two parts of [RFC5234]. The two 
changes are as follows: 


o Replace the last half of Section 2.3 of [RFC5234] (beginning with 
"ABNF permits the specification of literal text strings") with the 


contents of Section 2.1. 


o Replace the <char-val> rule in Section 4 of [RFC5234] with the 
contents of Section 2.2. 
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2.1. Terminal Values - Literal Text Strings 


ABNF permits the specification of literal text strings directly, 
enclosed in quotation marks. Hence: 


command = "command string" 


Literal text strings are interpreted as a concatenated set of 
printable characters. 


NOTE: 

The character set for these strings is US-ASCII. 

Literal text strings in ABNF may be either case sensitive or case 
insensitive. The form of matching used with a literal text string is 


denoted by a prefix to the quoted string. The following prefixes are 
allowed: 


ae 


case-sensitive 


s 
i = case-insensitive 


ae 


To be consistent with prior implementations of ABNF, having no prefix 
means that the string is case insensitive and is equivalent to having 
the "Si" prefix. 


Hence: 


rulename = %i"aBc" 


and: 
rulename = "abc" 


will both match "abc", "Abc", "aBc", "abC", "ABc", "aBC", "AbC", and 
" ABC " S 


In contrast: 
rulename = %s"aBc" 


will match only "aBc" and will not match "abc", "Abc", "abC", "ABc", 
" aBC " y "AbC " 7 or "ABC " 7 


In the past, the numerical specification of individual characters was 
used to define a case-sensitive rule. 
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For example: 


rulename = $da97 %d98 %d99 
or 
rulename = %x61.62.63 


will match only the string that comprises only the lowercase 
characters, abc. Using a literal text string with a prefix has a 
clear readability advantage over the old way. 


2.2. ABNF Definition of ABNF - char-val 


char-val = case-insensitive-string / 
case-sensitive-string 


case-insensitive-string = 
[ "Si" ] quoted-string 


case-sensitive-string = 


wo 


$s" quoted-string 
quoted-string = DQUOTE *(%x20-21 / %x23-7E) DQUOTE 
; quoted string of SP and VCHAR 
; without DQUOTE 
3. Security Considerations 
Security is truly believed to be irrelevant to this document. 
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